1. Field of Invention
This invention relates to a method of data management, and more particularly, to a method of data management wherein the characteristics of the data elements being collected are known. The exemplary embodiment of this method is a vote data management system.
2. Description of Prior Art
Data management technology exists because the computer source code for all data-intensive computer applications can be organized into three quite distinct modules: the user-interface functions, the application functions, and the data-serving functions. Conventional data management systems capitalize on this natural organization by creating a generalized data management system that can be used in a wide variety of applications.
These generalized data management systems present the application programmer with an extension to her programming language that provides the data-serving functions. The application programmer calls these functions from inside the application code. This process is called embedding.
However, embedded generalized data management systems are inherently inefficient because, as these programs run, the specific data must be transformed into a generalized format for storage and transformed again, back to the natural format, on retrieval. Storing the data in the generalized, unnatural, format almost always takes much more storage space than storing them in their natural format.
In addition, generalized data management systems can only supply the application programmer with low-level data-serving functions, like "save.sub.-- record" and "fetch.sub.-- record". The programmer must deal with the complex task of transforming the specific data to fit a generalized record format.
This task is accomplished by 1) writing the code to fill up and unfill the records, and 2) setting up schema, or maps of the record formats. Because these things must be done before the computer program is compiled, the resulting application is incapable of run-time flexibility in its schema definitions. Indeed, in conventional data management art, it is understood (Object Data Management, page 215, by R. G. G. Cattell, Addison-Wesley Publishing Company, 1991) that no automatic and satisfactory schema-evolution capability is possible because generalization to a variety of data types necessitates too many possible transformations of the schema and the data.
In the software industry, there are (at least) several programs developed in response to each computable problem. For example, several software companies make warehousing applications. Sometimes the several programs developed for one problem rely on the same-data management system. This means that the task of generalizing the specific data must be duplicated by each developer. So, while using a generalized data management system circumvents the need for some duplicate code, it also creates a need for other duplicate code.
Worse yet, the work of evolving the schema, if it is possible at all, must be done by personnel at the end-user site, with the help of utility programs supplied by the application programmer.
The exemplary embodiment of this invention is a data management system for maintaining vote data for groupware systems. Groupware is the name given to any computer hardware/software system that helps people cooperate in some way. The most common form of groupware, and the form to which the exemplary embodiment of this invention is most immediately applicable, is the computer conferencing system, sometimes called a bulletin-board. These conferencing systems invite an on-line community to post and read information in an organized way.
In groupware art, there are almost no methods for collecting votes from an on-line community. One make-shift vote-keeping method is outlined in the booklet, Customizing the Caucus(TM) User Interface (Camber-Roth, Troy, N.Y., November, 1990).
The Caucus conferencing software works with the Unix operating system. As with most conferencing systems, the text posted to the system by its users is organized as an outline is organized. The major categories under discussion are called conferences. Each conference has a title. A user starts a discussion by creating an "item of discussion". To do so, the user is required to enter text and a title for the new item. The titles for these items are listed on an "contents" screen.
An example of a prior-art contents screen is shown in FIG. 1. The list of item titles is under the "ITEM TITLE" heading 20.
Users can continue the discussion on a particular item by adding a message to the item. The number of messages added to each item is listed under the "RESPONSES" column 22 on the contents screen. The item number is listed under the "ITEM #" column 24.
The instructions recommend that votes be collected at the item level by using the messages as ballots: to vote "yes", the user adds a message with "YES" in the text body; to vote "no", the user adds a message with "NO" in the text body.
The votes are tallied and reported by a utility program that is run by the end-users from inside the conferencing program.
The utility program searches the messages for the "YES" and "NO" strings, counts the number of each, and reports the results to the user. This method, although clever, cheap, and useful, is inflexible, slow, and cumbersome to use. It does not allow numeric or grouped votes (as explained below), does not provide opportunity for collating votes from different computer sites, and does not allow users to query the vote data, to change their votes, or to place restrictions on the vote values or the manner in which the votes are collected, tabulated, and/or reported.
Many of the deficiencies of the Caucus method can be remedied, according to current art, by embedding a generalized data management system into the groupware's source code. However, as described above, the embedding task is somewhat large and difficult and the resulting system would either require much more storage space and processing time, or require constant human intervention to keep the schema up-to-date.